Fee Bumping・RBF・CPFP

LNDでは、未確認のトランザクションの手数料を引き上げて、迅速なブロックへの取り込みを促すために、Fee BumpingとRBFとCPFPの機能が提供されています。

RBF（Replace-By-Fee）

RBF（Replace-By-Fee, 手数料による置換）は、未承認のBitcoinトランザクションを、より高い手数料で再送信することでブロックへの優先的な取り込みを促すメカニズムです。Lightning Networkのチャネル運用やオンチェーン処理（特にLNDのsweeper）でも活用されます。

RBFの基本

未承認のトランザクションがmempoolにある状態で

同じインプットを使い（≒二重支払い）

より高い手数料を付けた別のトランザクションを作成し

古いものを置き換える（replace）

置き換えるtxはtxidが変わる

Bitcoinノードがそのトランザクションを受け入れるには、いくつかの条件を満たす必要があります。

RBFを有効にする条件（BIP 125）

Bitcoin CoreはRBFをサポートするが、明示的にRBFを示す必要がある。主な条件：

"nSequence" を非最終値（< 0xffffffff）に設定する → これにより「このトランザクションはreplaceableですよ」と明示できる。

新しいトランザクションは、すべての置換対象よりも高いfee rateを持つこと。

置換元に依存する未承認のトランザクションもすべて置換対象に含めること。

拒否される可能性

多くのノード（Bitcoin Core 標準設定）は BIP125 Opt-in RBF をサポートしますが、一部のノードでは「first-seen」（最初に見たトランザクションのみ採用）しか許容せず、RBF シグナル付きトランザクションを跳ね返します。

そもそもフル RBF（シグナリングなしでも置き換え可）を使うノードもあれば、まったく RBF を許さないノードもあり、ノード運用者の設定次第で置き換え可否は変動します

BIP125 の要件を満たさない場合の拒否

BIP125 では、置き換え元トランザクション以上の絶対手数料増加かつ手数料率（sats/vB）の増加が必須です。

もしどちらか一方だけしか増えていないと、他ノードは「条件不十分」と判断して拒否します

メモリプールのリソース制限

各ノードは「親子関係のトランザクション数」「バイト数」「パッケージサイズ」などでメモリプールの容量制限を設けており、替え玉が大量の未確定子孫を持つと拒否されることがあります

特に、多くの prevout を一度に置き換えるような大規模パッケージはデフォルトでは 100 トランザクションまでしか置き換えできず、それを超えるものは他ノードに弾かれます。

サービスノード・ウォレット挙動の違い

取引所やライトクライアントなど商用サービスが独自のメモリプール仕様・プライベートポリシーを使っている場合、RBF をまったくサポートせずに強制的に first-seen 処理することがあり、置き換えトランザクションがエンドユーザー間で共有されないことがあります。

実例

RBFのやり方（Bitcoin Core CLI）

トランザクション送信時にRBFを有効にする：

bitcoin-cli sendtoaddress <address> <amount> "" "" true

最後の true が "replaceable": true を意味します。

その後、手数料を上げて再送信する：

bitcoin-cli bumpfee <txid>

これで、Bitcoin Coreが自動的に新しいトランザクションを作成し、元のトランザクションを置換します。

LNDでのRBF活用

LNDは sweeper モジュール内部で、特定のトランザクションに対してRBFを使います。特に以下の状況で活躍します：

強制クローズされたチャネルの出力を回収（sweep）する必要があるが、手数料が低くて確認が遅れているとき

Deadline（例えばHTLCのtimeout前）に間に合わせるために、手数料を自動で引き上げてRBFする

CPFP（Child-Pays-For-Parent）

CPFP（子が親の手数料を肩代わりする） は、未確認の 親トランザクション の確認を早めるために、

その出力を使って新たに子トランザクション（Child Tx）を作成し、高い手数料を支払う戦略です。

これにより、マイナーは「親＋子の合計手数料」が高ければ両方ともブロックに含めたくなるため、親トランザクションも結果的に早く承認されます。

なぜCPFPが必要？

Bitcoinでは：

トランザクションがmempoolにある限り、ブロックに入るには十分な手数料（fee rate）が必要。

一度送信されたトランザクションは通常変更できない（RBFを使っていない場合）。

つまり、feeが低い親Txを送ってしまったが、RBF未対応である場合、

→ CPFPが唯一の手段になる。(マイニングプールにお金を払うことで早く取り込む方法もある)

マイナーはトランザクションの 「ツリー全体」 の合計fee rateを見て判断。

たとえ親Txのfeeが0 sat/vBでも、子Txが高feeであれば セットでブロックに入れるインセンティブが生まれる。

利用手順

code:CLI / JSON-RPC

1. listunspent で親の change UTXO を特定

2. createrawtransaction で子トランザクションを組立

3. fundrawtransaction + settxfee で高い手数料を指定

4. signrawtransactionwithwallet → sendrawtransaction で発信

（多くのウォレットが bumpfee RPC は RBF 用ですが、CPFP 用にも同様のワークフローで自動化されています）

メモリプールの制限と carve-out ルール

Bitcoin Core など多くのノードは、メモリプール内の 先祖数／子孫数を 25 件以内 または パッケージ総 vsize を 101 000 vB 以内 という制限を設けています

これを超えて子トランザクションを投入すると "too-long-mempool-chain" で拒否されることがあります。

ただし carve-out ルール により、上限 25 descendant を使い切っていても、トップレベルの親に対して 1 つだけ、最大 10 000 vB の追加子孫を許可します

LNDでの活用パターン

| 出力 | 内容 | 所有者 | RBF可否 |

| ----------- | ------ | --- | ------------------- |

to_remoteの場合、RBFができない理由

自分が署名していない／できない出力

to_remote 出力は、相手側の公開鍵でロックされているため、自分は その出力を使って新たなトランザクションを作成できない（秘密鍵を持っていない）

よって feeを上げる新しいRBFトランザクションも作れない

対応策：Anchor Output + CPFP

これを補うために、**Anchor Channel（アンカーチャネル）**が導入されました（BIP 330 に関連）：

commitment tx に 小さな「anchor」出力（330 sat） を追加

自分はこのanchorを使って、CPFP（Child Pays For Parent）戦略で手数料を引き上げられる

Commitment Tx

├─ to_local（自分） ← RBF可能

├─ to_remote（相手） ← RBF不可能

└─ anchor output（自分）← CPFP可能

この anchor output は 自分が使用可能なUTXO なので、自分で高feeの子トランザクションを作って commitment tx をブロックに含めやすくするのです。

| 観点 | to_local | to_remote |

| ------ | ---------- | ----------- |

| 所有者 | 自分 | 相手 |

| 秘密鍵 | 持ってる | 持ってない |

| RBF可能？ | ✅ 可能 | ❌ 不可能 |

| 解決策 | RBF / CPFP | Anchor CPFP |

LNDのSweeperモジュール

LNDのSweeperモジュールは、未確認の出力（UTXO）を監視し、適切なタイミングで手数料を調整してトランザクションを再送信する役割を担います。特に、チャネルの強制クローズ時やHTLCの期限切れが迫っている場合に、資金を安全に回収するために重要です。

Sweeperは、各出力に対して以下の情報を基に処理を行います：

期限（Deadline）：出力を回収すべきブロック高。

予算（Budget）：回収に許容される最大手数料（satoshi単位）。

これらの情報を元に、Sweeperは動的に手数料を調整し、必要に応じてRBFを利用してトランザクションの手数料を引き上げ、期限内の確認を目指します。